My main focus as far as AROS programming has been picture datatypes, 
picture viewers, MultiView, graphics programs and icon tools. But It 
didn't start that way. My adventures in AROS programming began modestly. 
I suppose you might say it started with a simple "Hello AROS World".

My history with AROS began maybe seven years ago with a simple goal and
some first steps in c programming. I wanted to focus on something useful
that would benefit the most AROS users as possible so I decided to focus
my attention on picture datatypes since graphics design is one of my main
interests. So working with pictures seemed like a nice fit for me to start.
That was my stated goal at the beginning but my first program wasn't about 
picture datatypes. It was a small command line program to split a PNG icon.
It was an icon splitter for dual-PNG icons that split images to Ram Disk.
I still have it and I update it with some new features from time to time.

The first program was to help learn c programming, especially the use of
variables, string handling and memory management which are completely and
surprisingly different than c# programming. But I wanted to focus attention
on my goal of updating some picture datatypes to benefit the most people.
Ater some initial research into picture datatypes I quickly realized that
something was missing. AROS was supposed to be Amiga compatible but ILBM
datatype was incomplete. So I began the process of writing a save function
for ILBM datatype so that MultiView could use the menu item "Save As IFF".
At first SaveILBM seems like it should be very straightforward as far as
programming. But there are two possibilities for saving the files - one is
SaveBitmapPic (<=8 bpl) and the other is 24 bit images, SaveRGBPic (24 bpl).
So SaveILBM will direct traffic based on depth to one of the save methods.
I had thought about including SaveHamPic to convert 24 bit to save as Ham8. 

But at that time I had a goal but I didn't know much about c programming 
and more importantly I didn't know anything about the ILBM file format.
So for the first year I researched and found everything I could about the 
image format. I found an informative article "EA85" about IFF-ILBM that was
an article by Electronic Arts. I learned quite a bit from the documentation.
For testing purposes I setup a test program for testing updates for ILBM
datatype. It was initially called "TestPicture" and it was for command line.
It quickly became the test program for several picture datatypes then the
name changed to "ShowPicture". It was easy to type in the command line and
it had become a graphics program based on picture datatypes. The code was
very messy and I still use it for testing sometimes. It still works as it
was intended and the program can be compiled in a AROS shell quite easily.
It's just a window with a menu sytem. There is no user interface for it.
Using ShowPicture as the test program I pioneered many of the image and
icon functions as well as graphics functions that I have begun to add to
some of my newer graphics and icon programs such as a future Icon Edit.

Once the SaveILBM function was working inside ShowPicture I was almost
ready to add it to the ILBM datatype. But as I mentioned already there is
a complexity to saving ILBM images. Saving bitmap pictures that are only
8 bitplanes or less was well documented. So SaveBitmapPic was working in
ShowPicture after about a year of research and testing. But saving 24 bit
RGB data as ILBM "deep images" was much more difficult. After another 6
months it was also complete and it worked well enough. But the code was
really quite messy and I was still relatively new to AROS c programming.
On a side project at that time I spent another year working on SaveHamPic
which allows converting 24 bit images to allow saving them as Ham6 or Ham8.
For the research and testing of SaveHamPic I used ShowPicture again for it.

Rather than jumping right into adding code to the ILBM datatype it seemed
better to acquaint myself with the datatypes system first to become more
familiar with Datatypes Library and the various kinds of picture datatypes.
Many of my C# projects dealt with BMP file format so I was quite familiar
with the Windows Bitmap (BMP) file format. So I chose to update the BMP
picture datatype. I noticed that it too seemed like a relatively simple
file format and I didn't understand why someone hadn't already updated it.
BMP datatype had the LoadBMP function but it lacked the SaveBMP function.
Whomever wrote the LoadBMP function based it on SaveGIF for GIF datatype.
But the picture formats aren't even similar. It would have been better to
base LoadBMP on the Targa Datatype since they have many more similarities.
The old LoadBMP function didn't work at all. So essentially I could re-use
the datatype descriptor, BMP__OM_NEW & BMP__DTM_WRITE which are the entry
points into the picture datatype for Datatypes Library & the SuperClass.
The rest of the BMP datatype was completely re-written for load and save.

So I went back to ShowPicture to write a LoadBMP function from scratch. 
It came together very quickly. In about 2 weeks it was complete and it 
worked well in the test program. So I moved LoadBMP to the BMP datatype. 
While writing the LoadBMP function in the test program I wrote in a way
that would make it very easy to convert into an actual picture datatype.
So plugging it into the datatype was without issue. Then I set about the
the same procedure for writing SaveBMP. I first wrote it in ShowPicture.
Then I added it to BMP datatype as SaveBMP. I was planning to write yet
another picture datatype called "BMPX datatype" but I quickly realized 
that Datatypes Library might get confused with the datatype descriptor. 
So instead I chose the easier route. I included the LoadBMP & SaveBMP 
functionality to support loading and saving 32 bit BMP files with alpha.
The code was added directly to BMP datatype rather than a new datatype.

After the initial success of updating (re-writing) BMP datatype I felt
that I was now ready to update ILBM datatype by adding SaveILBM to it.
After a brief detour to help Kalamateee and Mazze to update GIF datatype
I started adding the SaveILBM as well as SaveBitmapPic and SaveRGBPic.
But after the code to Save ILBM images was added to ILBM picture datatype
MultiView still refused to enable the "Save As IFF" menu item. I was not
completely sure why that didn't happen automatically. So I looked into it.

So about 5 years ago I started looking at the code for MultiView to find
out why it wasn't working to save IFF-ILBM images. It seemed that SaveIFF
was disabled in the conf file which contained all the various functions.
But enabling the menu item didn't change anything as far as enabling to 
save IFF-ILBM. Something else was missing from the AROS dataypes system.
So I had to do some more research to find the missing parts that needed
to be updated. When I asked the developers on ABIv1 where I needed to put
the SaveILBM functions in the Datatypes System to allow saving the files
no one seemed to know the answer, or maybe they didn't feel like admitting
that they hadn't succeeded in writing the save functions so they didn't 
want to get involved in the discussion of how and why it wasn't working.
Since I didn't get additional information I decided to find it for myself.

After much more research I realized that each picture datatype has another
datatype associated called the "SuperClass". For picture datatypes it is 
"picture.datatype" and for text it is "text.datatype" and for sound it is
"sound.datatype". So now it seemed I also had to update Picture Datatype.
I concluded that the conf file might provide some insight so I went back
to it. In the conf file I noted that DT_Write was disabled for some reason.
So I lookded at the code for Picture Datatype where the DT_Write should be.
I compared Picture Datatype to Text Datatype for DT_Write (for printing).
So I added SaveILBM in a condensed form in DT_Write for Picture Datatype. 
Also it was necessary to enable DT_Write in an associated datatype conf file.
After compiling the new Picture Datatype using the Picture Datatype Creation
Tool by Yannick it was time for more testing. Surprisingly MultiView worked.
Now "Save As IFF" successfully saved the IFF-ILBM images, both Bitmap & RGB.

After the initial successes of updating BMP, ILBM & Picture Datatypes I
went on to update a few more picture datatypes including Targa, PCX, Info
datatypes. I also wrote TIFF datatype based on Tiff Library since AROS
didn't have a TIFF datatype at the time. But there are some issues with
Tiff Library not working with MultiView. Once that is resolved it should
work as it was intended. Either Tiff Library needs to be made into a shared
library or TIFF datatype needs to be completely re-written to use only native
methods to load and save Tiff images which would involve a lot of extra work.
Additionally, I had thought about writing a dedicated Tiff Viewer that would
use native methods to load and save Tiff image files including multi-images.
More editing and testing will need to be done for AROS x86. All previous
development and testing of TIFF datatype was done on AROS x86_64 for ABIv1.

About 2 years ago I contacted Fredrik Wikstrom about his Targa and PCX
datatypes that are located in Contrib folder for AROS. He gave permission
for me to add the SaveTGA and SavePCX functions for the datatypes and he
added me to his Amiga OS4 projects for the datatypes, though I don't know
anything about Amiga OS4 programming. Once they are both complete I might
add the code to the OS4 projects and send it to him to be added to them.
Targa datatype is almost done excepth that Targe RLE (run length encoding)
is not fully working. It isn't well documented so it is mostly trial and
lots of error. But saving uncompressed 24 bit Targa files works correctly.
PCX datatype is complete and working correctly though the code is messy.

Info datatype is another picture datatype (icon datatype) Fredrik Wikstrom
wrote. He also wrote Ico datatype, and Icns datatype which are both icon
datatypes (multi-image format). All the datatypes are lacking save functions. 
But for multi-image format datatypes how do we go about saving a new icon?
For simplicity I added a save function for Info datatype that saves ILBM.
That will be the template for multi-image icon datatypes. The save function
will be the native file format for the icon images themselves for simplicity.

Other than that JPEG datatype received a minor update to allow loading and
saving 8 bit black and white JPEG image files which are not a common format.
There was also a small change to allow JPEG datatype to work with AROS 68k.
Other than Targa and PCX datatypes which I have permission to change and my own
Tiff datatype I don't foresee any other needed changes to the picture datatypes.

I believe that the updates to ILBM datatype and DT_Write for Picture Datatype
are the last contributions that I made to the AROS source code before I was
suddenly "uninvited" one day from the ABIv1 discussion group. There was no
reason given but I suspect it was due to a disagreement with the group leader.
That had happened before with the leader of the Apollo Team and that is why
they split off to form their own discussion group and a fork of AROS 68k.

Because of the difficulties involved with the ABIv1 development group I tend
to shy away from any major system updates for AROS. The last major update was 
for MultiView but I don't believe I officially released those changes. Not yet.
Nowadays I prefer to write my own programs for AROS so that I can do things in
my own way. Usually they consist of small utility programs for icons or graphics.

My new goal is to write a lot of small icon tools where each one includes the
functionality that will be needed for other tools. Each small icon tool will
pioneer a new set of fuctions that can be re-used later. AROS Icon Edit is
the goal of the icon tools development. It will be for AROS what Icon Edit is
to Amiga OS 3.x and Amiga OS4. I remember the nostalgia of seeing that icon.
What Amiga user could ever forget the yellow and green box of crayons icon?

My other programming interests are file systems and disk imaging. I have recently 
started writing DiskReader and SerialDiskReader for use with the DrawBridge project 
and the DrawBridge USB Floppy Drive to read real Amiga Floppy Disks on AROS x86.
After some initial success with my newest IconPress small icon tool as far as
writing the image data bitstream decoder algorithm maybe my c programming skills
have improved enough that I can write a DiskReader and SerialDiskReader program?





 